Various mechanisms exist for saving power by suspending computer execution and for implementing a multi-boot computing device. In systems of the prior art, a single operating system (OS) is typically booted at a time. If a second OS is needed, the computing device must be powered down and the firmware rebooted. Typically, there are standards governing the boot process such as the basic input/output system (BIOS) boot specification or the extensible firmware interface (EFI) boot manager. The user chooses which OS to boot. One scenario for requiring multi-boot machines might be in the case where a user uses an application running on Linux to surf the world wide web, but must use an application running on Microsoft® Windows™ to retrieve corporate e-mail. Switching between the two OSs requires a significant amount of time; one incurs the costs of rebooting the entire machine. On a desktop computer it might take 8–9 seconds to reboot the firmware, but on a server it may take up to two minutes to reboot the firmware. Further, after reacquiring and initializing the hardware devices, the OS needs to be loaded and started up, as well.
A single OS environment typically has power requirements, i.e., meeting U.S. EnergyStar ratings. An exemplary requirement might be for the machine to only dissipate 100 Watts. The Advanced Configuration & Power Interface (ACPI, see http://www.acpi.info) is an industry specification jointly developed by Intel Corporation, Microsoft Corporation, Toshiba Corporation and Hewlett-Packard Company to identify standards for managing power. Sleep states and transitions are defined in the ACPI specification. For instance, there is an ACPI specification that defines how to build hardware to support an S4 sleep state. Hibernate (S4) is used to save power—deep sleep. In order to hibernate into S4, the OS takes all of its memory contents and saves them to a disk file. This contrasts with a Standby (S3) state, where contents of memory are retained. A small amount of power is provided to the system random access memory (RAM) and the chipset to catch or listen for a wake event, for instance the lid of a laptop opening. In state S4, everything is powered off.
In state S4, when returning from Hibernate, the system does not need to rediscover the hardware installed in the system or reload all of the device drivers and discover the platform state. The OS initial loader realizes this is an S4 resume and asks the firmware to help it load the disk file back into memory. Memory holds a snapshot of the system and this snapshot is restored upon the resume.
A possible scenario for hibernation follows. A user is in a meeting in a conference room with a computer powered on and booted up. The user requests Hibernate mode, closes the laptop lid and go back to an office. All contexts of current operation are saved, including the machine context. Once back in the office, the user opens the lid and resumes. A 128 MB file, for instance, is then loaded from hard drive to memory. If the OS changed the hardware state from the time of the original boot up, for instance, modification of an IO port state, then this modified context is retrieved during the resume. Microsoft® Windows™ uses suspend, hibernation and resume modes extensively. However, at present, there is no way to resume from a hibernation mode in one OS to a resume into a different OS. A reboot process is required to change operating system environments.